Working with Redundant License Managers

To work with redundant licenses, a License Manager pool needs to be set up at your customer's end. The primary License Manager in the pool is designated as the leader—the remaining License Managers become followers. As long as the primary License Manager is up, all the tokens remain with the leader License Manager and are not passed to other License Managers in the pool. Below is a typical sequence of events:

1.A client sends a license request to the primary License Manager.

2.The primary License Manager establishes a connection with the client and grants the license after successful authentication.

3.When the primary License Manager (leader) goes down, it transfers all the tokens to the next leader—the follower License Manager having the highest precedence. 

a. When the current leader is down and the client is calling explicit LSUpdate (or sntl_licensing_refresh_attr for Unified API-based licensing implementations) API calls within the key lifetime period, the client library uses the failover list to switch this client to next available leader.

NOTE   It must be noted that this functionality is supported only when the LSUpdate or sntl_licensing_refresh_attr API is called.

So,  when the contacted License Manager goes down, the current update returns success, however it sets the status in handle to VLS_CONTACT_FAILOVER_SERVER. And, on the next update call, the client library makes use of the failover list to contact the next immediate server. The status value can be fetched using:

•Traditional API: The VLSgetLastErrorStatusFromHandle API function.

•Unified API: The sntl_licensing_get_session_info API function.

b. If none of the License Managers from the failover list are not reachable, the last update call fails.

c.This transition or this failover mechanism is transparent to the client application. Here, no special handling is required when current License Manager goes down. However, the client application is expected to call update API periodically.

NOTE   A dying License Manager does not pass the detailed client information (such as the license sharing details) to the new leader. However, if any existing client sends an update call to the new leader, this information is built up again. In general, a shorter key life time period ensures earlier replenishment of the client information.

4.As explained above, the in-use licenses are not lost and continue to be served seamlessly as the new leader License Manager reserves the tokens that are already issued. However, these tokens will be maintained until the waiting period elapses. The waiting period (first update period) is calculated as follows:

a.The waiting period to free the licenses = The number of redundant License Managers in the pool * the key lifetime defined in the license

b.Thus, if no updates are received during the waiting period, the new leader License Manager converts those tokens into free tokens. If it receives the update within the first update period, it updates the client information and waits for the next successive update from the clients which is the “key lifetime” defined in the license. If the successive updates do not arrive within the key lifetime period, the tokens are again converted into free tokens.

Example

>Suppose there are five redundant License Managers (S1, S2, S3, S4, S5, where S1 is the current leader) in a pool and the key lifetime of the redundant license X is 5 minutes.

>Let’s say, License Manager S1 goes down. and the next-highest priority License Manager S2 takes the lead.

> Initially, License Manager S2 waits for the first update calls from the clients. The waiting period is equivalent to the number of redundant License Managers in a pool * the key lifetime defined in the license (i.e. 5 X 5 = 25 minutes).

• If the update from the clients do not come in 25 minutes, all those tokens become free.

•If the updates are received before 25 minutes, then the License Manager S2 again waits for successive updates from the clients. The waiting period is now the lifetime period of a license, 5 minutes. If again, the updates do not reach within 5 minutes, all those tokens become available for reuse.

5.If ever, the primary License Manager (the old leader) comes up, it reclaims leadership and the control is transferred back to the primary License Manager.

NOTE   If a license expires, the leader License Manager generates an error message (LS_LICENSE_EXPIRED) for any further requests. The license update requests will be moved to the next (follower) License Manager, however, the LS_INSUFFICIENTUNITS error will be returned. This is because the next License Manager will have zero available tokens.

The contact server can be set using one of the following options.

>Unified API: SNTL_ATTR_APPCONTEXT_CONTACT_SERVER_LIST

>Traditional API: VLSinitServerList

>Environment Variable: LSHOST [S1~S2~S3]